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ABSTRACT 

The number of researchers, articles, journals, conferences, 
funding opportunities, and other such scholarly resources 
continues to grow every year and at an increasing rate. Many 
services have emerged to support scholars in navigating par- 
ticular aspects of this resource-rich environment. Some com- 
mercial publishers provide recommender and alert services 
for the articles and journals in their digital libraries. Simi- 
larly, numerous noncommercial social bookmarking services 
have emerged for citation sharing. While these services do 
provide some support, they lack an understanding of the 
various problem-solving scenarios that researchers face daily. 
Example scenarios, to name a few, include when a scholar 
is in search of an article related to another article of inter- 
est, when a scholar is in search of a potential collaborator 
for a funding opportunity, when a scholar is in search of an 
optimal venue to which to submit their article, and when 
a scholar, in the role of an editor, is in search of referees 
to review an article. All of these example scenarios can be 
represented as a problem in information filtering by means 
of context-sensitive recommendation. This article presents 
an overview of a context-sensitive recommender system to 
support the scholarly communication process that is based 
on the standards and technology set forth by the Semantic 
Web initiative. 

Categories and Subject Descriptors 

H.3.5 [Online Information Services]: Web-based ser- 
vices; H.3.7 [Digital Libraries]: Collection; G.2.2 [Graph 
Theory]: Graph algorithms 
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1. INTRODUCTION 

The purpose of a recommender system is to help fulfill the 
resource requirements of the individual enacting the service. 
For resource-rich environments, recommender systems serve 
as an information filtering tool that reduces the search space 
to some human- mangeable subset 16 . Within this sub- 
set, the individual is better able to identify those resources 
that meet their current requirements. However, understand- 
ing the current requirements of an individual is a difficult 
problem. For example, there are issues surrounding recom- 
mendations based soley on usage data. While a particular 
resource was necessary in the past (e.g. the "Elmo's ABC 
book" was needed for a colleague's child's birthday), it may 
not be a good predicator of future requirements (e.g. the 
child's birthday has passed). Thus, the problem of rec- 
ommendation is exacerbated by the fact that the require- 
ments of an individual fluctuates according to their context 
(i.e their ever-changing resource requirements). 

Members of the scholarly community face a variety of con- 
texts each with different resource requirements [Tt]. For 
example, scholars may need to: 

• identify articles related to some interesting resource, 

• identify collaborators for a funding opportunity, 

• identify a publication venue for a newly created article, 

• identify referees to review an article, and 

• identify resources of interest in one's community. 



General Terms 

Recommender system, scholarly communication process, multi- 
relational graphs, random walk algorithms. Semantic Web 



This article presents a context-sensitive recommender sys- 
tem to support the scholarly communication process. This 
system is called kReefQ kReef maintains a resource-rich, 
graph-based model of the scholarly community that includes 
people, articles, journals, conferences, calls, funding oppor- 
tunities, institutions, etc. and their various relationships 
to one another. kReef utilizes this model to execute al- 
gorithms that codify problem-solving strategies in order to 
support scholars in various contexts. This article provides 
an overview of the kReef system from its data structures and 
algorithms to its user interface. 



^kReef is currently available at http : //k-reef . com. 



2. SYSTEM ARCHITECTURE 

The foundation of kReef is a rich model of the scholarly com- 
munity that includes various resource types and their rela- 
tionships to one another. It was determined that the most 
appropriate standards and technologies to support such mod- 
eling are those set forth by the Semantic Web initiative i2j. 
Thus, kReef can be considered a Semantic Web technology. 
Figure ^ diagrams those kReef components that will be dis- 
cussed in this article. 
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Figure 1: The subset of the kReef system to be 
discussed in this article ranging from data storage 
to user applications. 



3. THE QUAD STORE 

kReef 's abstract data model is the quad-based representa- 
tion of the Resource Description Framework (RDF) 12|^. 
If U is the set of all Uniform Resource Identifiers (URI), B 
is the set of all blank/anonymous nodes, and L is the set of 
all literals, then a quad-based RDF graph is defined as 

G C (U U B) X U X (U U B U L) X (U U B), 

where any {s,p,o,g) G C is called a quad (or quad-based 
statement). The element s is the subject, p the predicate, 
o the object, and g the graph (or context). It is the role 
of g to partition triple-based RDF statements of the form 
o). Thus, two RDF statements that maintain the same 
g are considered in the same graph. Figure [2] diagrams an 
RDF quad. 



Figure 2: A quad is an o, ^) G G. 



An RDF quad store is a graph database that supports the 
representation and manipulation of RDF quads. Prior to 
the development and popularization of the quad concept, 
RDF stores were triple stores. Triple stores only support 
the (s,p, o) construct. However, it has become apparent 
that statement metadata (i.e. reification) can be more ef- 
ficiently represented using quads as opposed to the more 



verbose rdf : Statement construct In kReef, the g com- 
ponent of a quad serves as an identifier denoting a specific 
user's graph. Every time a user makes a statement, that 
statement is written to their graph — to their g. Currently, 
on the front-end, every user has a single graph unique to 
their account. In the future, users can have multiple graphs 
with different permissions. These permissions are controlled 
using Access Control List (ACL) metadata 15 . 

kReef uses Neo Technology's Neo4j graph database as its 
quad store Neo4j makes use of a linked graph data struc- 
ture in order to ensure optimal performance in graph traver- 
sals (i.e. vertices have direct pointer's to their adjacent ver- 
tices). As will be explained later in the article, kReef reason- 
ing and recommendation is not accomplished through typ- 
ical monotonic description logics and reasoners as popular- 
ized and proselytized by the Semantic Web community !]. 
Instead, kReef performs reasoning and recommendation by 
means of the random walk algorithms popularized by the 
graph/network analysis community For this reason, a 
quad store architecture that is optimized for traversals is a 
necessary requirement of kReef. Moreover, given the size 
of the scholarly community, a quad store that can scale to 
multiple billions of statements is another requirement. Neo4j 
meets both these needs. 

4. A SCHOLARLY ONTOLOGY 

As previously discussed, the abstract data model for kReef 
is a quad-based RDF graph. The ontologies (or schemas) to 
structure the data are discussed in this section. kReef cur- 
rently maintains two ontologies: cor^and relatioij^ The 
core ontology represents objectively determinable resource 
and relationship types found in the scholarly community (see 
^4.1). The relation ontology provides a set of predicates 



that are more subjective in nature (see ^.2) 



4.1 The Core Ontology 

The core ontology is represented in the Web Ontology Lan- 
guage (OWL) 14 . OWL is a web-based, description logic 
language used to define class descriptions in order to infer 
which resource instances are subsumed by which classes. In 
kReef, the core ontology primarily serves as a schema to aid 
in data modeling]^ The form of the core ontology was in- 
spired by the MESUR ontology [19] of the MESUR project 
Figure [s] diagrams the rdf s : subClassOf hierarchy of 
core, where core : Reef source is a direct rdf s : subClassOf 
of owl: Thing. For the core: Event branch, Jennifer Gol- 
beck's WWW04photo ontology provided inspiration|^ Note 

^Neo4j is currently available at http://neo4j .org/. 
^The core namespace prefix resolves to 
http: //knowledgereef systems . com/2007/ll/core#. 
^The relation namespace prefix resolves to 
http : //knowledgereef systems . com/2008/02/relation#. 
^Currently in kReef, ontologies are primarily used as 
schemas and not for description logic reasoning. The 
only reasoning rules currently supported by kReef are the 
rdf s : subClassOf and rdf s : subPropertyOf rules of the 
RDF Schema (RDFS) ruleset. The primary reason for this 
is that the computational complexity of description logic 
reasoning is high and it is necessary to ensure that kReef 
is a real-time system. However, into the future, kReef will 
support user generated owl: Class descriptions. 
^WWW04photo ontology is currently available at 
http : / / www . mindswap . org/ ^golbeck/ web/ www04photo . owl. 
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Figure 3: The rdf s : subClassOf hierarchy of the core ontology. The solid lines represent explicit rdf s : subClassOf 
relations and the dashed lines represent implicit rdf s : subClassOf relations. Each owl: Class has a two character 
"chemical" abbreviation used to visually denote a resource's rdf : type in the webtop user interface (see ^8]). 



that not all owl: Classes are presented in Figure [S] Some of 
the owl : Classes that are not represented pertain to support 
owl: Classes for the backend (e.g. user account data, quad 
store data management, access control lists, etc.). 

The core ontology maintains many owl : ObjectProperty 
and owl :DatatypeProperty relations. The most frequent 
ones are presented for each of the primary components of the 
core ontology: core : Reef source (see Table [l]), core : Agent 
(see Table[2|, core: Item (see Tablejs]), and core:Event (see 
Table[4]). For the sake of brevity, owl : InverseProperty and 
owl : Restriction information is not presented. 



Table 1: core : Reef source rdf :Property relations 



rdf : Property- 


rdf s : domain 


rdf s : range 


core : title 


core : Reef source 


xsd: string 


core : abstract 


core : Reef source 


xsd: string 


core : guid 


core : Reef source 


xsd: string 



Table 2: core: Agent rdf : Property relations 



rdf : Property- 


rdf s : domain 


rdf s : range 


core : attends 


core : Agent 


core : Event 


core : created 


core : Agent 


core : Item 


core : member 


core : Group 


core : Person 


core : subGroup 


core : Group 


core : Group 


core : f irstName 


core : Person 


xsd: string 


core : lastName 


core : Person 


xsd: string 


core : occupation 


core : Person 


xsd: string 


core : sex 


core : Person 


core : Gender 



Table 3: core: Item rdf : Property relations 



rdf : Property 


rdf s : domain 


rdf s : range 


core : cites 


core : Item 


core : Item 


core : containedin 


core : Item 


core : Collection 


core : creationTime 


core : Item 


xsd:dateTime 


core : doi 


core : Item 


xsd : anyURI 


core : publisher 


core : Item 


core : Group 


core : dueDate 


core : Call 


xsd:dateTime 


core : callFor 


core : Call 


core : Reef source 


core : contains 


core : Collection 


core : Item 


core : editor 


core : Collection 


core : Agent 


core : isbn 


core : Collection 


xsd : anyURI 


core : issn 


core : Collection 


xsd : anyURI 


core : oaipmh 


core : Library 


xsd : anyURI 


core : startPage 


core : Article 


xsd: int 


core : endPage 


core : Article 


xsd: int 


core : number 


core : Article 


xsd: int 


core : volume 


core : Article 


xsd: int 



Table 4: core: Event rdf : Property relations 



rdf : Property 


rdf s : domain 


rdf s : range 


core : startTime 


core : Event 


xsd:dateTime 


core : endTime 


core : Event 


xsd:dateTime 


core : presents 


core : Event 


core : Item 


core : organizedBy 


core : Event 


core : Agent 


core : subEvent 


core : Event 


core : Event 



4.2 The Relation Ontology 

The purpose of the relation owl: Classes is to represent 
typed relationships between two resources and metadata 
about those relationships. In many ways, these owl : Classes 



are for reificiation. Unfortunately, given that g is used to 
identify a user graph, to reify a statement with extra meta- 
data, an rdf : Statement-hke construct is required. Figure^ 
diagrams the relation owl : Classes, where the rdf s : domain 
and rdfs: range of their supported rdf : Property data are 
single directed edges. 
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Figure 4: The relation ontology. Each rdf : Property 
is represented as a single edge, where the rdfs : domain 
is the tail of the edge and the rdfs: range is the head 
of the edge. 

The purpose of the relation : related owl : Class is to allow 
a user to explicitly denote their subjective interpretation of 
the similarity between two resources. Moreover, users can 
provide an xsd: float core: weight to denote the strength 
of similarity. This core: weight is a real number in [0,1], 
where denotes a weak similarity and 1 denotes a strong 
similarity. The most prevalent use of related: relation is 
to relate a core: Concept to a core : Reef source. This is 
how users "tag" resources. Given that a core: Concept is 
an rdf s : subClassOf core : Reef source, users are also able 
to relate a core: Concept to another core : Concept. Thus, 
in the colloquial sense, users can "tag tags". All created 
relation: related statements are written to the user's g 
graph. This is how relation: related resources are tied to 
their creators. The role of relation: related is presented 
in 301 and 3831 



The purpose of relation: usage is to track the "resource 
path" that a user takes through kReef. When a user views 
one resource and then another, a relation: usage resource 
is created. For example, if at time step t = 1, a user views 
resource i and then at t = 2 the user views resource j, then 
a relation: usage resource is created (if one does not al- 
ready exist between i and j in that user's g). This rela- 
tion: usage resource denotes i as its core: subject and j as 
its core: object. Moreover, time stamp t — 2, which is rep- 
resented as an xsd:dateTime, is turned into an xsd: string 
and recorded as the rdfs: range of the core :usageSt amps. 
If the relation: usage resource between i and j already 
exists for that user, then the t — 2 time stamp value is 
appended to the already existing core :usageStamps list. 
Again, because each g is associated with a user, it is possi- 
ble to determine at which time a particular user moved from 
resource i to resource j. 

5. TRANSLATORS 

The ontologies defined in ^provide an abstract model of the 
scholarly community. In order to be useful, this abstract 
model must be populated with instances. The translators 



component serves this purpose. There are numerous trans- 
lators that continually harvest scholarly data and represent 
it according to the previously presented ontologies. Fortu- 
nately, the scholarly community maintains a massive digital 
footprint that is represented in various repositories world- 
wide. The Open Access Initiative's Protocol for Metadata 
Harvesting (OAI-PMH) of the digital library community is 
an excellent mechanism for harvesting scholarly metadata 
|13| . An example translation of an OAI-PMH feed is pro- 
vided below for the arXiv record oai : arXiv . org : 0807 . 2466 



<record> 
<header> 

<identif ier>oai : arXiv . org: 0807 . 2466</identif ier> 

<datestamp>2009-01-07</datestamp> 

<setSpec>cs</setSpec> 
</header> 
<metadata> 

<oai_dc :dc> 

<dc:title>A Grateful Dead Analysis ... </dc :title> 
<dc : creator>Rodriguez, Marko A . </dc : creator> 
<dc : creator>Gintautas , Vadas</dc : creator> 
<dc : creat or>Pepe , Albert o</ dc : creat or> 
<dc : subject>Computers and Society</dc : subject> 
<dc : subj ect>General Literature</dc : subj ect> 
<dc : sub j ect>K . 4 . 0</ dc : subj ect> 
<dc : description> 

The Grateful Dead were an American band . . . 
</dc : description> 
<dc : date>2008-07-15</dc : date> 
<dc : type>text</dc : type> 
<dc : identif ier> 

http:// arxiv.org/abs/0807.2466 
</dc : identif ier> 
</oai_dc :dc> 
</metadata> 
</record> 



The record presented is represented in the Dublin Core (dc) 
schema]^ There is a simple mapping from the dc schema 
to the core and relation ontologies. Given this record, 
the arXiv translator will create a new core : Article. The 
core : title of the core : Article is determined by dc : title. 
The core : abstract of the core: Article is determined by 
dc : description. The core:url of the core: Article is de- 
termined by dc : identif ier. The core:guid of the created 
core: Article is the identifier oai: arXiv.org: 0807. 2466. 
Next, three core: Person resources are created for the three 
dc: creators and they are connected to the core: Article 
using core : created. The arXiv repository is considered a 
"user" in kReef and thus, arXiv has its own g. In this way, it 
is possible to track which digital library repository provided 
which data. Moreover, given that arXiv has its own g, the 
dc : subject categories in each arXiv record is represented as 
a relation: related association between the core: Article 
and the core : Concept identified by dc : subject. This is how 
arXiv "tags" its resources. Finally, various rules are used to 
ensure that duplicate resources are not created. 

Other OAI-PMH feeds provide richer metadata such as jour- 
nal and citation information. Also, other sources for schol- 



^This record has been doctored to improve readability and 
for the sake of brevity. Also, for more information on the 
arXiv pre-print repository, please visit http : //arxiv . org. 
^The dc namespace prefix resolves to 
http: //purl . org/dc/elements/1 . 1/. 



arly metadata come from various RSS and ATOM feeds. 
More information about the kReef data providers can be 
found at http: //k-reef .com. Finally, users are able to cre- 
ate and relate resources using the kReef webtop interface 
discussed in ^ However, except for relation: usage data, 
most of the data in kReef comes from external repositories. 

6. GRAMMAR WALKER ENGINE 

In the current release of kReef, there are three recommender 



applications: Discover (see ^8.2), Reasoner (see J 8.3), and 
News (see J 8.5). The grammar walker engine is the kReef 
component that supports these applications. The engine 
executes functions similar in nature to constrained spread- 
ing activation 8 and the class of relative rank algorithms 
[23|. Gammar-based random walkers are random walkers 
designed specifically for multi-relational graphs [iS]. Most 
random walk techniques require a single-relational graph. 
However, an RDF graph is multi-relational as it supports 
multiple types of relationships between vertices (i.e. there 
can be multiple predicates in an RDF graph). Along with 
some other process information, a grammar is an abstract 
path that a walker takes when traversing a multi-relational 
graph. The purpose of the algorithm is to identify resources 
related to some initial set of seed resources. The concept of 
"relatedness" is determined by the grammar that the walker 
uses. 

The grammar walker engine works as follows. Grammar 
walkers are initially distributed to a collection of seed re- 
sources and given a defined grammar. Next, they traverse 
the graph and increment counters for certain resource types 
they meet along the way as defined by their grammar]^ Each 
walker has a time decaying "energy" value e G M that they in- 
crement the resource counter with. The decay function gov- 
erning the loss of walker energy is et+i = ^et, where S G [0, 1] 
is the decay parameter. When the walker energy decays be- 
low a given threshold or a certain number of prescribed steps 
have been taken, the process is complete. What is returned 
are the counters on the resources. This yields a ranked list 
that denotes those resources that are most related to the 
seed resources (according to the topology of G and the gram- 
mar being used) . Currently, all the recommender algorithms 
utilized in kReef make use of the grammar walker engine, 
where the grammar is tailored to particular problem-solving 
scenarios. In general, the success of graph-based methods for 
recommendation over correlation-based methods have been 
demonstrated in [10] , 

A simple coauthorship grammar demonstrates the process. 
If a set of core : Agents are needed that are "coauthor-related" 
to some set of seed core: Agents, then a coauthor grammar 
is used. Suppose a multi-relational graph with the following 
edge types and respective domains and ranges: 



• core : created : core: Agent core: Item 

• core : createdBy : core : Item core : Agent 



Given these edge types only, there does not exist an explicit 
coauthorship graph. However, two core: Agents are deemed 



coauthors if they have core: created the same core: Item. 
In order to traverse a coauthorship graph, a traversal of 
core: created and core : createdBy edges must be used. In 
order to ensure that a coauthorship graph is traversed, upon 
taking the core : createdBy edge, the grammar walker must 
not traverse to the same core : Agent it was located at on the 
previous step — as a core : Agent can not be their own coau- 
thor. Also, only core: Agent resources have their counter 
incremented as the traversed core : Items are not coauthor- 
related to the seed resources. Formally, if 



1 if o, *) G C 
otherwise. 



I is the {0, l}-identity matrix, pi represents core : created, 
and p2 represents core : createdBy, then the graph traversed 
by the grammar walker is defined as (A^^ • A^^ ) o (1 — I) A 
diagram of this process is presented in Figure |5] Finally, an 
algebraic framework for representing any arbitrary grammar 
is presented in [22]. 




Figure 5: An example of a coauthorship grammar 
walk. There exists a single grammar walker de- 
noted by the gray filled circle. The number in the 
walker denotes the time step at which the walker is 
at each resource. When the walker has a bold out- 
line, the walker is updating the counter of its cur- 
rent resource. For the sake of diagram clarity, the 
core : createdBy owl : InverseProperty is not presented. 



7. ANALYTICS 

The analytics aspect of kReef provides statistics on resources. 
There are many ways to quantify the "value" of a resource in 
the scholarly community: the Impact Factor ^ , the H-Index 
pr] , the Y- Factor 4 , etc. Many of these statistics can be 
easily derived in a quad store using SPARQL queries [19| . 
Moreover, given the amount of usage data that kReef records 
(i.e. relation: usage), it is possible to provide statistics on 
how resources are used . The benefit of the analytics com- 
ponent is that it provides a user a quantified understanding 
of the impact of various resources in the scholarly commu- 
nity. 

8. WEBTOP 

The kReef webtop provides a desktop look and feel within 
a typical web browser. A user can have multiple windows 
open, can drag and drop resources between windows, and 
can shrink windows to conserve screen real-estate. The 



^In certain cases, especially for the Reasoner grammars, 
walkers can decrement counters. 



^"^The operator o is the Hadamard entry- wise multiplication 
operation. 



webtop applications currently supported are itemized below, 
where the f-annotated applications are those that provide 
recommendations: 

• View: used to view a resource 

• Discover^: used for generic recommendations 

• Reasoner^: used for context-specific recommendations 

• Organize: used to bookmark resources 

• News^: used to identify community interests 

• Search: used for typical keyword searchj^ 

8.1 View 

View is analogous to a web browser, but instead of viewing 
HTML documents, the View renders subgraphs of the un- 
derlying RDF graph in a user-friendly manner. Each core 
owl: Class has its own specific rendering method. For in- 
stance, what data is gathered and rendered for a core : Person 
is different than the data that is gathered and rendered 
for a core: Article. Also, through View, users are able 
to modify and add information to a resource (i.e. they can 
add owl :DatatypeProperty and owl : ObjectProperty infor- 
mation). Figure [g] provides a screenshot of a core: Person 
View that is rendering the core: Person resource with the 
core : title "Marko A. Rodriguez "'^'xsd: string. Note that 
every owl: Class has an associated two character "chemical" 
abbreviation. The abbreviation for core: Person is "Pe". 
The abbreviations for each owl: Class are diagrammed in 
Figure [3] 





profile 


name 




created 


Marko A. Rodriguez 




membership 
attended events 


description 

digital iibrariansiiip, computational eudaemonics, graph theory, 
science, government architecture, network metrics, decision 


network 
support 


organized events 


systems... 




tags 


occupation 




acknowledgements 
account 


Researcher 
birthdate 

11/30/1979 

uri 

http://www.linkedin.com/in/markorodriguez 

http://cnls.lanl.gov/~marko 

http://markorodriguez.com 




' ' all related resources 


T 1 > help feedback 


modify 





Figure 6: A screenshot of a core: Person View. The 
left hand side has various tabs. The right hand side 
provides the information contained in the currently 
selected tab. 

8.2 Discover 

The Discover appUcation is the simplest recommender appU- 
cation. Discover maintains a single general-purpose gram- 
mar that allows traversals along nearly all paths (except 
paths that will lead into the graph representation of the on- 
tology). Furthermore, particular composite paths are accen- 
tuated such as coauthorship, co-citation, co-event, etc. In 

Given the simplicity of Search, there will be no dedicated 
subsection. In brief. Search is analogous to standard key- 
word search and returns a ranked list of those resources 
that have a user specified keyword in their core: title or 
core : abstract. 



previous research, these composite paths have been deemed 
significant indicators of r elatedness [2l]. Moreover, usage 
information is utilized in a collaborative filtering manner 
to identify co-used resources of interest ^ . The only user 
settings in Discover are the seed resources and the desired re- 
turn types (e.g. core: Agents, core : Documents, core: Events, 
etc.). Figure [7| presents a screenshot of Discover. 



1 [pe] Marko A. Rodriguez [remove] 


[pe]Herbert Van de Sompel 


1 [pe]johan Bollen [remove] 


[or] Los Alamos National Laboratory 




[pTjUennifer H. Watkins 




[pe]Alberto Pepe 




(aT] Initial Experiences Re-Exporting Duplicate and Similarity 




Computation with an OAI-PMH aggregator 




[ArjAutomatic Metadata Generation using Associative 




Networks 




[pe]Michael L. Nelson 




[pej Frank McCown 


[ all related resources H)hj > 


help feedback 



Figure 7: A screenshot of Discover. The left hand 
side has the user-provided seed resources. The right 
hand side has the recommended resources. 

8.3 Reasoner 

More context-senstive recommendations are provided by the 
Reasoner application. Reasoner yields targeted solutions to 
particular scholarly problems. Current reasoning grammars 
can: 

• provide initial resources with which to explore an idea, 

• determine a core : Group of well suited collaborators, 

• locate a core : FundingOpportunity to financially sup- 
port an idea, 

• locate an appropriate core : Collection or core : Event 
to which to submit a core : Article, and 

• determine the most appropriate referees to review a 
core : Article. 

Grammars for these particular problem-solving situations 
are currently designed according to intuition and have been 
validated using a small subset of test users The only rea- 
soning grammar that has been rigorously validated through 
algorithmic techniques is the last grammar in the itemized 
list above: identify referees who are competent to review a 
submitted core : Article. Validation of this reasoner was 
originally presented in 20 , where the algorithm is able to 
make a statistically significant distinction between experts, 
non-experts, and conflict of interest referees. A description 
of this grammar is as follows. Given core: Article i, the 
user wants to identify a group of non-conflict of interest ref- 
erees competent enough to review i. The authors of the 
core : Articles that are core : citedBy i provide a set of 
competent referees. Moreover, the coauthors of the cited 
authors are also competent referees (recursively with decay- 
ing S significance). However, authors tend to cite themselves 

Currently, approximately 20 users contribute to validating 
the Reasoner grammars. 



and their collaborators. Thus, to remove conflict of inter- 
est referees, authors and the author's coauthors should be 
removed (recursively with decaying S). The ranked list re- 
turned provides a collection of expert referees for article i. 

8.4 Organize 

Organize is analogous to a file system, but instead of orga- 
nizing files, users organize resources. When a user creates a 
relation: related resource associating a core : Concept to 
a core : Reef source, the core: Concept serves the function 
of a "folder" and the core : Reef source serves the function 
of a "file" in that folder. Organize can also be thought of 
as a bookmark application where users can save resources 
they have found in kReef for later use. However, beyond 
bookmarking. Organize plays a significant role in the News 
recommendation application (see ^8.5). 



8.5 News 

There is no such thing as an explicit "social network" in 
kReef. For one, there is no notion of "friendship". Users, 
like other scholarly artifacts, are resources. However, a user 
is a multi-faceted entity that can be considered a resource 
for various ends. For example, when user i tags user j with 
core: Concept /c, user i is stating that they respect/trust 
user j in the area of core : Concept k. Thus, the social graph 
that emerges is a multi-relational graph denoting how users 
respect each other. Moreover, this multi-relational social 
graph serves as a medium for propagating targeted resources 
between users. The purpose of the News application is to 
allow users to view this propagation. In this way. News 
serves as a type of context-sensitive RSS feed which recom- 
mends resources of interest in the user's community. Figure 
[8] provides a screenshot of the News application. 
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|cn] artificial intelligence 

[c^artificial life 

Jcnj collective decision making 

[cnj collective intelligence 

Jcnjcomplexity science 
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[wsjDebatabase 

Debatabase is the world's most useful resource for student 
debaters. Inside you will find arguments for and against 
hundreds of debating Topics, wr.. 

(swjTruthMapping.com: Home 

TruthMapping.com is a free tool that provides a focused, 
rational method for adversarial discussion that overcomes 
the limitations of standard mess... 

[swj Groupspace.org 

Groupspace.org is a host for Deme (pronounced: deem), 
our web-based platform for online deliberation (formerly 
referred to as "POD"). Deme is being... 

(^Agentlink Technical Forum Group on Argumentation 
Interchange Formats / 2005 

Argumentation theories provide a powerful framework for 
interacting agents making a decision, assessing the validity 
of a fact, or otherwise resolv... 



(i.e. relation: related) according to core:Concept k. The 

walkers then traverse to all the resources that this set of 
users have tagged as k. If one of those resources is yet an- 
other user, then the process repeats. Each time a walker tra- 
verses an edge, it decays its energy according to the exponen- 
tial decay function et-\-i = 2~^^^et, where A is the difference 
in time between the current time and the core : insertTime 
of the relation: related resource and a is the half- life of 
the significance of the association. The exponential decay 
function ensures that those resources that have been more 
recently relation: related are more highly recommended. 
Ultimately, what is returned is a ranked list of those re- 
sources tagged as k that are topologically near user i in the 
multi-relational social graph generated by k. 

Figure |9] provides and example of how News works. This 
example is from the perspective of user krs:marko and ac- 
cording to the "semantic web" core : Concept. If krs:inarko 
wants to get recommended "semantic web" resources in his 
News application, a grammar is executed that follows "se- 
mantic web" relation: related edges from krs :markop^ 
Given that krs:marko does not respect krs:gary according 
to "semantic web", he does not see krs : gary's krs : software 1 
resource. Even though krs : marko respects krs : dave in terms 
of "semantic web", he does not see krs : dave's krs : webpagel 
recommendation as it is tagged "Java". Given that krs : josh 
respects krs : apepe in terms of "semantic web" and krs : apepe 
respects krs : articlel in terms of "semantic web", krs : marko 
sees both krs: apepe and krs: articlel in his "semantic 
web" recommendation. Note that krs: dave and krs: josh 
are not recommended to krs : marko because these resources 
are already explicitly respected by krs: marko. 
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Figure 9: An example "semantic web" News recom- 
mendation for the krs: marko user. The highlighted 
resources are the recommended resources. 



Figure 8: A screenshot of the News application. The 
left hand side denotes the user's core : Concepts and 
the right hand side denotes the various resources 
that his respected/trusted core: Agents have tagged 
according to those core : Concepts. 

All of the core : Concepts that a user has in their Organize 
application can be seen on the left hand side of the News 
application. When user i clicks on core: Concept /c, user i 
diffuses a swarm of News grammar walkers. The grammar 
walkers are seeded on all the users that user i has tagged 



9. CONCLUSION 

kReef is a service that supports the scholarly communication 
process. Many of the standards and technologies of the Se- 
mantic Web initiative have been incorporated into its design 
and implementation. Additionally, kReef takes advantage of 
the graph structure of its data set by applying techniques 
from the network analysis community. Among these tech- 
niques is a general-purpose framework for performing ran- 
dom walks in a multi-relational graph. The grammar walker 

Realize that these are not explicit statements in the quad 
store as relation: related is a collection of statements. 



engine currently serves as the core recommendation tech- 
nology in kReef. This engine derives intuitive, personalized, 
context-sensitive recommendations from harvested and user- 
generated data. The webtop user interface delivers these rec- 
ommendations to users in real time. The future of kReef will 
include not only more algorithms tailored to scholarly con- 
texts, but also an infrastructure to support virtual and real- 
time scholarly communication that is believed to be more 
efficient and effective than the scholarly communication in- 
frastructure present today. 
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